Testing Trophy
このわけのわからん図が何を言っているか
https://gyazo.com/3a2a026df9749507f3bf4fc306931096
frontendのテストを3(+1)つに分類しました
static checkはtestではないが、有用なので描いておきました
昔はtestの分類が複雑過ぎ(unit testだけで20種類ぐらいあった)てやってられなかったので新しく定義した
右側のわけわからん図の面積の比率がテストの記述量に対応している
要するにIntegration testの比率を高めるべきということが言いたい
そのためにわざわざわけわからん図を描いている
ピラミッドに対抗して、中間が膨れている物体を探したらトロフィーがあったのだろう
ここでのtestの分類
実際のユーザの動きと同じをする
アプリ全体のテスト
mockを使わないか、ごく少数のmockで、実際の環境でtest
複数のunit testを互いに統合したもの
1ページ全体のテスト
実装の詳細はテストしない
ユーザーから見える部分のみをテストする
mockはできるだけ使わない
MSWを使ったmockありのページ全体のテストとか
依存関係を持たないunitをテストする
個々のComponentのテスト
個々の独立した部品が期待通りに動作することを検証する
例えば1つの関数とか、1つのclassとか
Static
静的検査
3つのトレードオフ
cost
CI環境を用意する際のコストや、実働時間のコスト
Trophyの上に行くほど高価になる
そもそも時間がかかるし
失敗するポイントも増える
テストが壊れる可能性も高まる
修正にかかる時間もかかる
speed
testにかかる時間のことを指している
Trophyの上に行くほど時間がかかる
confidence
ここが主張の根幹mrsekut.icon
testは、そのsoftwareの利用シーンに似ているほど信頼性が上がる
@kentcdodds: The more your tests resemble the way your software is used, the more confidence they can give you. 自分の発言を引用してるんかーいとなったmrsekut.icon
Trophyの上に行くほど信頼係数(confidence coefficient)が上がる
E2Eより上にあるのは手動テスト、と言える
つまり、
costとspeedは下に行くほど嬉しいが、
confidenceは上に行くほど嬉しい
ここでトレードオフが発生している
そのため、Unit test書くべし、という感じだった。と
従って、Integration testを書くことで、トレードオフの良いとこ取りができる、と結論づけている
これが最もちゃんとTesting Trophyの説明している記事
4分類のtestの具体例も説明されている
「Testing Trophy」を参照する時はこれを参照しろmrsekut.icon
Componentのunit tesingという概念あるんだmrsekut.icon
しかし、この3つのトレードオフから、この結論を導くのは飛躍があるのではないかmrsekut.icon
Unit TestとE2Eを同じぐらい多く書いて、Integration Testはあまり書かない、という考え方もできる
そもそもこの3つのトレードオフが、同じぐらいの比重を置くべき指標なのかどうかも不明
ビジネスに依ってどこが重要なのかも変わる
Kent C. Doddsがこれを提唱したところまでは良いが、「Testing Trophyを参考にしました！」と言って、そのまま乗っかっている記事を見ると、ほんまにそれでええんか？？という気持ちになるmrsekut.icon 実例とか
もともとはE2Eテスト重視でtest実行に9分かかっていた
それをIntegration testに書きかえると1分半になった
Testの分類が不明瞭なので、E2E(Cypress)からIntegration(Testing Libary)に変えました、とだけ書かれても全然参考にならないなmrsekut.icon こういう記事は具体例がないと無意味かもしれない
あるいは、「E2E」とか「Integraion」という単語を使わずに「テストの抽象度を下げたら効率良くなりました」と言ったほうが良いかも知れない
あるいは、「Testing Trophy」の分類が完全に共有されている前提か
最初はこんな図だったらしい
A general guide for the **return on investment** 🤑 of the different forms of testing with regards to testing JavaScript applications.
- End to end w/ @Cypress_io ⚫️
- Integration & Unit w/ @fbjest 🃏
- Static w/ @flowtype 𝙁 and @geteslint ⬣
https://pbs.twimg.com/media/DVUoM94VQAAzuws.jpg
何を言っているか
fontendのtestを3(+1)種類に分類しました
最近のfrontendは、Integrationが大事です(根拠なし)
この記事はTesting Trophyという概念の説明はほぼしていない
時代の流れのようなものを説明しているだけ
mrsekut.iconはtestに関する時代の流れをあまり知らないが、この記事によるとこんな感じらしい
以前まではUnit testingだいじ！という感じだったらしい
最近は、Integration testingやろうぜ！という感じになってきているらしい
@swyx: The @MartinFowler Test Pyramid has fallen out of style. Integration > Unit tests is the new conventional wisdom.
In frontend, we now have the "Testing Trophy" from @rauchg and @kentcdodds.
In backend, @theburningmonk's course advocates the "Testing Honeycomb" from @SpotifyEng.
https://pbs.twimg.com/media/EYCwtegU0AESioV.jpghttps://pbs.twimg.com/media/EYCwv8xUYAA2X0e.jpg
「なぜIntegration testingやろうぜ！」なのかの理由はこの記事では一切語られていない
カバレッジを上げても意味ない
実装の詳細をテストするのは良くない
リファクタするときの速度が落ちるため
テストしたところでtestの信頼性が上がらない(?)
トロフィーの上のテストほど、実行に時間はかかるが、テストの信頼性は高い
「テストの信頼性が上がる」の根拠が書かれていないのでよくわからないmrsekut.icon
Integrationは信頼性と速度のトレードオフのバランスを取っているので良い
Integration tests strike a great balance on the trade-offs between confidence and speed/expense. This is why it's advisable to spend most (not all, mind you) of your effort there.
mockをやめよう